1. Field of the Invention
The present invention relates, in general, to authentication, authorization and accounting (AAA) service systems and, more particularly, to an AAA protocol-based accounting method using batch processing, in which only batch accounting process is decided in advance and used between peer networks to substitute a real-time accounting for batch accounting in order to process batch accounting between an AAA server and an AAA client from the first stage of the process, or which basically processes real-time accounting, and transmits failed accounting data later in a batch processing manner if the transmission of the accounting data fails, thus supplementing the transmission of the accounting data, and an accounting method.
2. Description of the Prior Art
Authentication, Authorization and Accounting (AAA) functions refer to the functions of processing authentication, authorization and accounting of subscribers. A strongest point of mobile communication is that a user can communicate with anyone, anytime, anywhere through roaming or handoff technology. If such roaming or handoff technology is realized over the Internet Protocol (IP)-based wireless Internet, a mobile IP protocol is used to allocate IP and support a mobile network. In mobile communications supporting the mobile IP, at the time of roaming, a mobile user must be authenticated by and allocated IP from a foreign network so as to be provided with wireless Internet services after automatically selecting and accessing a public Wireless Local Area Network (WLAN) or mobile communication network using his or her dual mode mobile phone or Personal Digital Assistant (PDA). Further, in order to bill the user for services, accounting technology is used between networks. Further, authorization technology is used as security technology for the authority of a roaming user. In this case, Network Access Identifier (NAI) expressed in the form of user@relam is used as an Identifier (ID) to identify a user or a mobile terminal. Different networks analyze NAIs to identify home networks of users and perform identification, authentication, authorization and accounting of the users.
Remote Authentication Dial-In User Service (RADIUS), which is prior art of AAA protocols, is a protocol for a small-sized network system that support only a small number of subscribers requiring client-server-based authentication. Therefore, RADIUS is not suitable for AAA services for communication service providers that must simultaneously support several hundreds to thousands of users on the basis of various technologies, and Internet service providers (ISP) that intend to steadily increase service capacities. Therefore, in order to solve the above problem, Diameter protocol has been developed.
Diameter protocol, which has been standardized as a draft for mobile IP/WLAN, can be defined as a Peer-based AAA protocol, which is simple and extensible to provide AAA services for conventional technology, such as Point-to-Point protocol (PPP), and new technology, such as roaming and mobile IP. A Diameter server can transmit messages fit for a Network Access Server (NAS) to process, and support reliable window communication-based transport, which can prepare for a communication failure. Moreover, a conventional RADIUS server cannot transmit messages if a client does not request the messages, while a Diameter server may transmit messages in case the Diameter server must inform the NAS of billing information or a connection release. Further, in the case of Diameter, retransmission and failure recovery functions are improved, and network recovery ability is higher than that of RADIUS with weak, slow characteristics. Further, Diameter is proposed to provide an end-to-end security technique, not supported by RADIUS, and support an extensible AAA protocol for a new generation, such as roaming and mobile IP network.
However, such an AAA protocol (Diameter) is designed so that application protocols are constructed on the basis of a base protocol, in which the base protocol itself performs an accounting function. Further, the AAA protocol is basically designed so that a real-time accounting function is obligatory and batch processing is excluded. Therefore, if the AAA protocol is applied as it is, the real-time accounting must be maintained. Moreover, if it is difficult to process accounting data due to a system overload during accounting or if accounting data cannot be normally processed due to a transmission failure, the accounting data, not processed, cannot be transmitted using the AAA protocol.
Diameter, having standardized recently, has many adaptabilities to accommodate a variety of services. However, as to the basic functions of authentication and accounting after authority verification, only a real-time accounting manner is specified in the base protocol. Further, Diameter specifies that only a single accounting record is transmitted by a one-time message (refer to IETF RFC 3588 <Diameter Base Protocol> P115, chapter 9.1). However, Diameter is problematic in that it cannot provide a batch processing technique having a real-time processing function and a function of processing accounting data failed in the real-time processing. Moreover, Diameter does not propose a method capable of executing simultaneous batch processing with respect to a plurality of accounting records.
FIG. 1 is a flowchart showing a real-time accounting process of AAA functions defined in the conventional AAA protocol (Diameter). As shown in FIG. 1, if an AAA server 11 receives a subscriber authentication request from an AAA client 12 at step 101, the AAA server 11 processes the subscriber authentication and then transmits a subscriber authentication response to the request to the AAA client 12 at step 102. Thereafter, if the AAA client 12 requests the AAA server 11 to transmit accounting message(ACR) at step 103, the AAA server 11 store accounting data to an accounting data storage 14 using a Diameter server base protocol 13, and transmits the response message(ACR) to the AAA client 12. At this time, if the accounting data transmission response succeeds at step 104-1, the AAA client 12 stores the accounting data in a first accounting data storage 16 using a Diameter client base protocol 15 at step 105. On the contrary, if the accounting data transmission response fails at step 104-2, the AAA client 12 stores the accounting data in a second accounting data storage 17 at step 106.
In FIG. 1, if the transmission of accounting data fails during the transmission after the AAA server 11 performs authentication, services provided to the AAA client 12 may be intercepted based on policies in some cases. For functions defined in the AAA protocol at the present time, an additional procedure or function does not exist in the case where the transmission of the accounting data fails or the transmission thereof is impossible during a routing procedure. That is, the AAA protocol specifies that real-time accounting must be implemented and an accounting function for batch processing is not supported. However, services connected to other networks do not realistically guarantee that accounting data is successfully transmitted in every case. Additionally, the influence of the services on a system load is so great that accounting cannot be performed in real-time. Therefore, real-time transmission may be meaningless, except for advance payment cards(Prepaid cards) or specially permitted specific subscribers confirmed in an authentication process. As added to the AAA protocol, having been recently completed in standardization, the accounting must be processed in real-time a later time. However, all problems cannot be solved using only the real-time accounting. That is, even though lower layers are designed on the basis of reliability, all failures of physical networks cannot be overcome. Therefore, a batch accounting function must be accepted to basically process real-time accounting, and supplement the real-time accounting according to accounting results to transmit the accounting data in a batch processing manner after a subscriber session has terminated. Especially, an accounting function in an AAA node needs to use batch processing as a selective method for a base protocol and requires a mechanism for processing batch accounting as an additional supplementary factor for failed accounting records at the time of real-time processing. The base protocol has required a function capable of accepting the mechanism.